|
|
|
|
|
|
|
theAccountCollection. The object theAccountCollection becomes a container of theInterestBearingChecking, theSavings, and theBankHolding. |
|
|
|
|
|
|
|
|
Designing and Modeling Subsystems |
|
|
|
|
|
|
|
|
As with classes, you might make some micro-level design decisions when programmatically grouping classes into subsystems. Some classes will be responsible for providing an externally visible interface to the services provided by the subsystem. Other classes will simply implement those services on behalf of the subsystem interface classes. There are two ways to construct subsystems: Expose several interface classes to external clients, or expose one interface class when the class is more of a broker. The former is more common with object repositories; the latter broker case is more common, in general, because it is really a design pattern. Table 5.2 contains some examples of these. |
|
|
|
|
| TABLE 5.2. SUBSYSTEM CLASSES. | | Class | Attribute | Method | | Savings | AccountNumber | calculateInterestRate() | | CurrentBalance | accrueInterest() | | InterestRate | deposit() | | | withdraw() | | InterestBearingChecking | AccountNumber | calculateInterestRate() | | CurrentBalance | accrueInterest() | | InterestRate | deposit() | | | withdraw() | | BankHolding | AccountNumber | calculateInterestRate() | | CurrentBalance | accrueInterest() | | InterestRate | deposit() | | TypeOfHolding | calculateTax() | | | transfer(ByVal argAmount, | | | ByVal argAccountNumber1, | | | ByVal argAccountNumber2) |
|
|
|
|
|
|
Programming broker classes is straightforward. It implies a delegation relationship between the broker class and the serving classes. Given a broker class BankHolding, the General Declarations section could include the following: |
|
|
|
|
|
|
|
|
Private theInterestBearingChecking As New _ InterestBearingChecking
Private theSavings As New Savings |
|
|
|
|
|